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Abstract 


The DNS Security Extensions (DNSSEC) requires the use of 
cryptographic algorithm suites for generating digital signatures over 
DNS data. There is currently an IANA registry for these algorithms, 
but there is no record of the recommended implementation status of 
each algorithm. This document provides an applicability statement on 
algorithm implementation status for DNSSEC component software. This 
document lists each algorithm’s status based on the current 
reference. In the case that an algorithm is specified without an 
implementation status, this document assigns one. This document 
updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6944. 
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Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


I; 


2: 


2; 


Introduction 


The Domain Name System (DNS) Security Extensions (DNSSEC) ([RFC4033], 
[RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702]) uses 
digital signatures over DNS data to provide source authentication and 
integrity protection. DNSSEC uses an IANA registry to list codes for 
digital signature algorithms (consisting of a cryptographic algorithm 
and one-way hash function). 


The original list of algorithm status is found in [RFC4034]. Other 
DNSSEC RFCs have added new algorithms or changed the status of 
algorithms in the registry. However, implementers must read through 
all the documents in order to discover which algorithms are 
considered wise to implement, which are not, and which algorithms may 
become widely used in the future. 


This document defines the current implementation status for all 
registered algorithms. If the status of algorithms changes, this 
document will be replaced with a new one establishing the new status; 
see Section 2.4. 


This document updates the following: [RFC2536], [RFC2539], [RFC3110], 
[RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933]. 


1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The DNS Security Algorithm Implementation Status Lists 
1. Status Definitions 


Must Implement: The algorithm MUST be implemented to interoperate 
with other implementations of this specification. 


Must Not Implement: The algorithm MUST NOT be implemented. An 
algorithm with this status has known weaknesses. 


Recommended to Implement: The algorithm SHOULD be implemented. 
Utility and interoperability with other implementations will be 
improved when an algorithm with this status is implemented, though 
there might be occasions where it is reasonable not to implement 
the algorithm. An implementer must understand and weigh the full 
implications of choosing not to implement this particular 
algorithm. 
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Optional: The algorithm MAY be implemented, but all implementations 
MUST be prepared to interoperate with implementations that do or 
do not implement this algorithm. 


2.2. Algorithm Implementation Status Assignment Rationale 


RSASHA1 has an implementation status of Must Implement, consistent 
with [RFC4034]. RSAMD5 has an implementation status of Must Not 
Implement because of known weaknesses in MD5. 


The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement 
as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ 
SHA-512 are also set to Recommended to Implement as major deployments 
(such as the root zone) use these algorithms [ROOTDPS]. It is 
believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace 
older algorithms (e.g., RSA/SHA-1) that have a perceived weakness. 


Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and 
ECDSAP384SHA384) is an algorithm that may see widespread use due to 
the perceived similar level of security offered with smaller key size 
compared to the key sizes of algorithms such as RSA. Therefore, 
ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement. 


All other algorithms used in DNSSEC specified without an 
implementation status are currently set to Optional. 


2.3. DNSSEC Implementation Status Table 
The DNSSEC algorithm implementation status table is listed below. 


Only the algorithms already specified for use with DNSSEC at the time 
of writing are listed. 


4+------------ 4------------ 4------------------- 4------------------- + 
Must Must Not Recommended Optional 
Implement Implement to Implement 
4+------------ 4+------------ 4------------------- 4------------------- + 
| | | | | 
| RSASHAlL |  RSAMD5 | RSASHA256 | Any | 
| | |  RSASHA1-NSEC3 | registered | 
| -SHA1 algorithm 
RSASHA512 not listed in 
| | | ECDSAP256SHA256 | this table | 
| | | ECDSAP384SHA384 | | 
4+------------ 4+------------ 4------------------- 4------------------- + 
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This table does not list the Reserved values in the IANA registry 
table or the values for INDIRECT (252), PRIVATE (253), and PRIVATEOID 
(254). These values may relate to more than one algorithm and are 
therefore up to the implementer’s discretion. As noted, any 
algorithm not listed in the table is Optional. As of this writing, 
the Optional algorithms are DSASHA1, DH, DSA-NSEC3-SHA1, and GOST- 
ECC, but in general, anything not explicitly listed is Optional. 


2.4. Specifying New Algorithms and Updating the Status of Existing 
Entries 


[RFC6014] establishes a parallel procedure for adding a registry 
entry for a new algorithm other than a standards track document. 
Because any algorithm not listed in the foregoing table is Optional, 
algorithms entered into the registry using the [RFC6014] procedure 
are automatically Optional. 


It has turned out to be useful for implementations to refer to a 
single document that specifies the implementation status of every 
algorithm. Accordingly, when a new algorithm is to be registered 
with a status other than Optional, this document shall be made 
obsolete by a new document that adds the new algorithm to the table 
in Section 2.3. Similarly, if the status of any algorithm in the 
table in Section 2.3 changes, a new document shall make this document 
obsolete; that document shall include a replacement of the table in 
Section 2.3. This way, the goal of having one authoritative document 
to specify all the status values is achieved. 


This document cannot be updated, only made obsolete and replaced by a 
successor document. 


3. IANA Considerations 


This document lists the implementation status of cryptographic 
algorithms used with DNSSEC. These algorithms are maintained in an 
IANA registry at http://www.iana.org/assignments/dns-—sec-alg-numbers. 
Because this document establishes the implementation status of every 
algorithm, it has been listed as a reference for the registry itself. 


4. Security Considerations 


This document lists, and in some cases assigns, the implementation 
status of cryptographic algorithms used with DNSSEC. It is not meant 
to be a discussion on algorithm superiority. No new security 
considerations are raised in this document, though prior description 
of algorithms as NOT RECOMMENDED (see [RFC4034]) has been recast as 
Must Not Implement. 
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